home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
gt_power
/
gth035.zip
/
ROUTING.HLP
< prev
next >
Wrap
Text File
|
1990-06-30
|
17KB
|
503 lines
╔═════════╦════════════════════════════════════════════════════════════
║ GT-HELP ║ ROUTING.BBS - the standard routing file.
╚═════════╩════════════════════════════════════════════════════════════
The routing file is used to prevent you from placing *direct* calls to
every node that you have mail for.
In theory, you don't need a routing file - if you don't have one, then
you simply call everybody in the nodelist direct.
In practice, almost everybody has one. Its usually cheaper and more
efficient to work through the local hub. Unless of course you *are*
the local hub - in which case you *certainly* need a routing file.
┌──────────────────────────────────────────────────────────────────┐
│ Simple Setup - all mail via a STATIC hub (ie, you call it daily) │
└──────────────────────────────────────────────────────────────────┘
PREFIXES LOCAL(+) DISTANT(*)
END
;
; As your hub is probably going to match the LOCAL prefix, it may be
; useful to set the DISTANT prefix (defined in the ALT-I screen, "*" in
; this case) to and invalid dialcode, which will prevent it from dialling
; Outer Mongolia if for some reason mail does not get consolidated properly.
;
; (This will however prevent you placing .DX calls to other nodes, so
; you may wish to remove it after you are sure all is OK).
;
; See Prefixes below for more information.
;
;
OUTBOUND NODES
050/001
END
;
; 050/001 is listed as outbound to make sure I call it every day, even
; if I have no mail to go there.
;
;
BAG CONSOLIDATION
050/001
END
;
; This creates a G bag containing all 050/001 mail (faster than
; separate bags)
;
;
ROUTING INSTRUCTIONS
FORWARD 001-899/000-899 -> 050/001
END
;
;
Everything to my hub - can't get much simpler than that.
;
┌────────────────────────────────────────────────────────────────────┐
│ Simple Setup - all mail via an ACTIVE hub (ie, it calls you daily) │
└────────────────────────────────────────────────────────────────────┘
The same as the above, but *delete* the OUTBOUND NODES section and
replace it with
INBOUND NODES
050/001
END
;
; Don't call this node, even if there is mail for it.
;
┌─────────────────────────────────────────────┐
│ Handling echos which somebody else sponsors │
└─────────────────────────────────────────────┘
For this example, lets assume the echos you need are :
E38/013 Northumberland Widgets
E42/293 Apathy Anonymous
a) Make sure that your hub is sending you mail in G bags.
b) Create directories for the message bases, add entries in GTMDIR.BBS
for the echos :
P ^D:\NORWID Northumberland Widgets (E38/013)
R ^E:\APATHY Apathy Anonymous (E42/293)
c) Add a message distribution section to your ROUTING.BBS :
MESSAGE DISTRIBUTION
E38/013 -> D:\NORWID ,Northumberland_Widgets
E42/293 -> E:\APATHY ,Apathy_Anonymous
END
d) Add the "upstream" information to the ROUTING section:
ROUTING INSTRUCTIONS
FORWARD 001-899/000-899 -> 050/001
ACCEPT E38/013 -> 050/001
ACCEPT E42/293 -> 050/001
END
e) Send a netmail message to your hub containing the request commands:
.GM E38/013
.GM E42/293
f) Ignore all references in documents to a REQUEST ECHOMAIL
CONFERENCES section. Unless the hub you are collecting it from is
running a very old version of the netmail software, the bag
consolidation method is a much more efficient way of collecting
echos.
┌──────────────────────────────────┐
│ Handling echos which YOU sponsor │
└──────────────────────────────────┘
a) Obtain an echo id and its CRC from your echo coordinator.
For this example, lets assume this is :
E27/123 Brontosaurus Spotting (CRC 2468-2ABC)
b) Create directories for the message base, add entries in GTMDIR.BBS
for the echo :
F ^D:\BRONTO Brontosaurus Spotting (E27/123)
b) Add a message distribution section to your ROUTING.BBS :
MESSAGE DISTRIBUTION
E38/013 -> D:\NORWID ,Northumberland_Widgets
E42/293 -> E:\APATHY ,Apathy_Anonymous
E27/123 -> D:\BRONTOS ,Bronto_Spot
END
d) Add the CRC information to the ROUTING section:
ROUTING INSTRUCTIONS
FORWARD 001-899/000-899 -> 050/001
ACCEPT E38/013 -> 050/001
ACCEPT E42/293 -> 050/001
ACCEPT E27/123 $2468-2ABC
END
e) Ensure that you are consolidating mail to the intended
destination(s). You can either add the echo line to the
consolidation section :
BAG CONSOLIDATION
050/001
E27/123
END
or have the other node put in a .GM message for the echo.
┌──────────────────┐
│ Handling Netmail │
└──────────────────┘
Apart from the ROUTING as mentioned above and described in more detail
later, the routing.bbs is not normally concerned with netmail.
The netmail area is defined by the ~ prefix in GTMDIR.BBS (described in
another menu) and you should set up at least one such message area.
┌────────────────────────┐
│ The Sections in detail │
└────────────────────────┘
All sections are optional, and can
simply be omitted if not needed.
Note that all sections begin with a heading and end with END.
The order of sections is unimportant.
┌──────────┐
│ Prefixes │
└──────────┘
Usually, a prefix entry is needed to distinguish between local and long
distance numbers. Typically :
PREFIXES LOCAL(+) DISTANT(*)
END
This specifies that:
a) "local" numbers (those in the nodelist that begin with the number
specified in AREA in my SCHEDULE.BBS) should be called by:
i) dialling the standard prefix, followed by whatever is
configured as prefix +, both as defined in GT's ALT-I
screen.
ii) *stripping off* the AREA code and dialling the balance of
the number from the nodelist.
iii) dialling the standard suffix as configured by ALT-I.
b) all other numbers should be called by:
i) dialling the standard prefix, followed by whatever I
configured as prefix *, both as defined in GT's ALT-I
screen.
ii) dialling the *full* number from the nodelist.
iii) dialling the standard suffix as configured by ALT-I.
If you are outside USA, you will probably need to segregate numbers
into at least THREE types. GT only provides two, which means that you
will not be able to call all possible destinations during the same
mailslot.
The easiest answer is to put most of the mail through a hub system.
Or, if you are the hub, to set up additional ROUTING files and operate
more than one mailslot.
┌────────────────────────────┐
│ Inbound and Outbound Nodes │
└────────────────────────────┘
By default, GT will CALL those nodes which it has mail for. It will
not call other nodes, nor will it call nodes whose mail is being
FORWARDED via another node (unless there is a DX message for that
node).
If there are nodes you wish to call even when though you have NO mail
for it, then you specify them as OUTBOUND. If working through a hub,
you would probably do that to ensure you place a daily call to pick up
any mail for you.
If there are nodes you do not wish to call even when you do have mail
for them, then you specify them as INBOUND. Usually it only makes
sense to do that if they are going to call you regularly. It is not
necessary to do that for nodes which are defined on the left side of an
ACCEPT or FORWARD statement.
Examples:
INBOUND NODES
050/030
END
OUTBOUND NODES
050/001
050/022
END
┌──────────────────────┐
│ Routing Instructions │
└──────────────────────┘
Types of instructions:
FORWARD 003-008/000-899 -> 050/001
All mail for all nodes (ie nodes 0 to 899) in nets 3 to 8
should be forwarded to 050/001
ACCEPT 020-020/000-899 -> 050/001
As well as forwarding any of your own mail to the specified
nodes, you will also ACCEPT such mail from other sources and
pass it on.
ACCEPT E34/246 $xxxx-yyyy
An accept statement for an echo you sponsor, where xxxx-yyyy is
your echo CRC.
ACCEPT E30/000-999 -> 050/001
A general 'upstream' routing for echo bags in a particular
series. Identifies where messages you enter in those echos
should be routed on their way to the sponsor. Generally
expected to be an ACCEPT rather than a FORWARD, since others
should be able to route their upstream echo bags via you.
Note: It is wise to check that your next destination has an
onward routing for any echos not sponsored there.
If the range overlaps an echo which you sponsor, be
sure the sponsored echo is listed first.
┌───────────────────┐
│ Bag Consolidation │
└───────────────────┘
In general, you should only include nodes that you connect with
directly in the consolidate list. Indirect connections automatically
receive indirect consolidation, according to the ACCEPT/FORWARD
definitions in the routing section.
BAG CONSOLIDATION
050/001,Q
E27/123
050/022,QZ
END
The ,Q indicates that the first node can handle Q bags. If a Q bag
exists for E27/123 it will be sent, otherwise an E bag will be used.
Note: Although E27/123 is shown listed here, it is usually better to
control echo consolidation either by the caller sending a .GM
request or using MEDIT. The problem is that putting it in the
routing file is a NON-reversible process - when you take it
out, the echo continues to be consolidated - which makes for
confusion.
The ,QZ indicates that the second node has also requested Zipped Gbags.
(default is to use PKARC). Use the zip option only if the recipient
requests it, it makes larger G bags.
┌─────────┐
│ Pursuit │
└─────────┘
Pursuit is a system available only to US users in certain areas. Its
format is :
PURSUIT
ACCESS=
USERID=
PASSWORD=
CITIES
201,NJNEW-Newark
216,OHCLV-Cleveland
202,DCWAS-Washington
305,FLMIA-Miami
206,WASEA-Seattle
All 33 (???) cities should be included.
END
┌───────────────┐
│ Long Distance │
└───────────────┘
This section is used to identify individual nodes, or a range of nodes
within a particular net, whose telephone numbers match the AREA entry
in SCHEDULE.BBS but should nevertheles use the Long Distance prefix (as
defined in the Prefixes section) rather than the local one.
LONG DISTANCE
001/002-005
002/020-022
END
┌──────────────────┐
│ Pickup Overrides │
└──────────────────┘
When MDRIV calls a number in your own net, it delivers mail and also
requests to pick up any mail for you. When it calls a number outside
your own net it will only *deliver* mail - unless the destination
matches an entry in the pickup list.
PICKUP OVERRIDES
003/004-005
END
┌─────────────────┐
│ Request Echo... │
└─────────────────┘
Echos now generally travel in consolidated bags -- so for most purposes
you can *ignore* this section.
You should certainly not list any echo here which is also being
delivered in a consolidated bag.
If you *do* need to use this section, eg if you are picking it up
direct from a board with an old version of netmail, its format is :
REQUEST ECHOMAIL
E00/002
E00/008
END
Such a request has to be used in conjunction with an ACCEPT statement
in the routing section, eg
ACCEPT E00/002 -> 050/001
defining 050/001 as the next upstream node, from which the distributed
echo bags are collected.
┌──────────────────────┐
│ Message Distribution │
└──────────────────────┘
Echos which you handle - whether as sponsor or subscriber - should
normally have an entry here.
MESSAGE DISTRIBUTION
E38/013 -> D:\NORWID ,Northumberland_Widgets
E42/293 -> E:\APATHY ,Apathy_Anonymous
E51/127 -> D:\XXXX ;Jam_Recipes (Topsecret)
END
The information after the comma is optional and purely for
identification. It is used as an archive comment when zipping the
messages and it is reported in response to a .GL request.
In greater detail :
┌──────────────────────────────────── Echo ID
│ ┌──────────────────────────────── Keep bags for 10 days
│ │ ┌──────────────────────────────── Generate Q bags
│ │ │ ┌────────────────────────── Message base path
│ │ │ │ ┌── Comma to include in .GL
│ │ │ │ ┌───────────────────┴── or Semicolon to exclude
│ │ │ │ │ ┌────────────────── Comment
│ │ │ │ │ │ ┌───────── Optional Password
───┴─── ─┘ │ ───┴─── │ ──────┴──── ─────┴─────
E51/127,10,Q -> D:\XXXX ; Jam_Recipes (Topsecret)
The Q option is appropriate only on echos which you sponsor.
A semicolon in place of a comma omits that echo from the .GL listing.
A word enclosed in parentheses (round brackets) acts as an encryption
password for the echo.
Note: A common error is putting a comment like (new) in parentheses
against a description - the echo gets unintentionally encrypted
using the comment as a password.
If you are a hub, you may be collecting echos which do not need to be
distributed into a local message base. Such echos do not need an entry
in the message distribution section.
DISTRIBUTING NETMAIL
--------------------
Normally, netmail does not need to have a distribution entry. In the
absence of instructions to the contrary, netmail will be distributed to
the first message base listed in GTMDIR.BBS with a ~ prefix.
If you have a lot of netmail from particular nets or nodes, then it is
possible to dedicate an area specifically to receive netmail from those
nodes :
a) set up an additional message area in GTMDIR.BBS, ensuring that it
has the ~ prefix and is listed *after* your main netmail area.
b) add an entry in the MESSAGE DISTRIBUTION section such as
050/001-999 -> D:\LOCALNET
which would have the effect of distributing messages from any node
in net 050 to the specified message base.
┌────────────────┐
│ Echomail Hours │
└────────────────┘
Used to restrict the time in which echo requests can be processed. An
exception to the normal section rules, this has no heading or end.
ECHOMAIL HOURS 0400-0500
Echomail now mostly travels in consolidated bags, which are exempt from
the restriction, so this statement is virtually obsolete.
┌────────────────┐
│ Excluded Nodes │
└────────────────┘
Normally you would not have any requirement to exclude any node, but
this section can be used to prevent certain nodes from calling you
direct.
EXCLUDED NODES
001/534
002/467
END